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Abstract 

Most  current  development  contracts  contain  separate 
requirements  for  accomplishment  of  logistics  and 
engineering  analyses.  In  many  cases  these  analyses 
are  interrelated,  and  accomplishment  of  one  may  be 
dependent  on  the  prior  completion  of  another.  Not 
all  engineering  analyses  have  direct  impact  on  acquisi¬ 
tion  logistics,  but  many,  including  most  reliability  and 
maintainability  (R&M)  analyses,  are  significant  fac¬ 
tors  in  determining  logistics  support  requirements. 
Additionally,  the  results  of  logistics  analyses  should  be 
used  in  selection  of  design  solutions.  Poor  planning 
and  lack  of  understanding  of  the  interrelationship  of 
engineering  and  logistics  can  lead  to  inefficient  use  of 
resources  and  lost  opportunities  to  improve  the  sup- 
portability  of  the  equipment  under  development. 

Using  experience  gained  by  the  authors  in  both 
engineering  and  acquisition  logistics,  this  paper  will 
attempt  to  demonstrate  the  need  for  integration  of 
logistics  and  engineering  development  planning.  The 
need  for  early  determination  of  analysis  responsibili¬ 
ties  and  schedules  will  be  discussed,  and  a  sample  of 
an  integrated  approach  to  logistics  and  engineering 
will  be  presented.  Integration  of  developmental 
engineering  and  logistics  analysis  efforts  required  by 
MIL-STD-785B  "Reliability  Program  for  Systems  and 
Equipment’’,  MIL-STD-470A  "Maintainability  Pro¬ 
gram  Requirement  for  Systems  and  Equipment",  and 
MIL-STD-1388-1A  "Logistics  Support  Analysis"  will 
be  the  primary  topics.  Also  discussed  will  be  the 
advantages  of  a  common  computer  for  accomplish¬ 
ment  and  storage  of  both  engineering  and  logistics 
analysis. 

Types  of  engineering  analysis  covered  will  be  R&M 
allocation,  prediction  and  measurement,  Failure 
Modes,  Effects  and  Criticality  Analysis  (FMECA), 
Built-In-Test  (BIT)  effectiveness,  and 
availability/operational  effectiveness  modeling. 
Covered  from  the  logistics  side  will  be  Repair  Level 
Analysis,  maintenance  task  analysis,  Reliability  Cen¬ 
tered  Maintenance,  spares  and  support  equipment 
quantity  determination,  and  Life  Cycle  Cost  analysis 
of  design  alternatives. 

OVERVIEW 

Department  of  Defense  (DoD)  acquisition  initiatives  in 
recent  years  have  increasingly  highlighted  supportabil- 
ity  engineering  as  a  design  discipline  capable  of 
significantly  increasing  the  amount  of  time  that  a  sys¬ 
tem  is  available  for  operational  use.  The  Air  Force 
development  community  has  responded  to  these  DoD 
initiatives  for  improving  system  reliability  and  main¬ 
tainability  (R&M)  by  increasing  the  emphasis  on  the 
systems  engineering  process  as  part  of  the  product 
division  acquisition  efforts  within  the  Air  Force  Sys¬ 
tems  Command  (AFSC).  Simultaneous  efforts  by  the 
acquisition  logistics  community  have  been  aimed  at 
predicting  the  support  resources  likely  to  be  consumed 


by  a  given  design  in  order  to  influence  the  selection  of 
design  alternatives  and  support  structure  alternatives 
that  will  result  in  the  lowest  system  life  cycle  costs. 
The  Air  Force  logistics  community  has  responded  to 
DoD  developed  standards  for  logistics  support  analysis 
by  assigning  a  Deputy  Program  Manager  for  Logistics 
(DPML)  and  a  staff  of  logistics  specialists  as  part  of 
the  product  division  acquisition  efforts  within  AFSC. 

Acquisition  logistics  programs  are  generally  structured 
to  comply  with  the  planning  and  analytical  frame¬ 
work  provided  in  MIL-STD-1388-1,  Logistics  Support 
Analysis  (LSA)  and  MIL-STD-1388-2,  DoD  Require¬ 
ments  for  a  Logistics  Support  Analysis  Record 
(LSAR),  both  developed  in  response  to  DoD  Directive 
5000.39,  Acquisition  and  management  of  Integrated 
Logistics  Support  for  Systems  and  Equipment.  R&M 
engineering  programs  are  generally  structured  to  com¬ 
ply  with  MIL-STD-785B,  Reliability  Program  Require¬ 
ments  for  Systems  and  Equipment,  and  MIL-STD- 
470A,  Maintainability  Program  Requirements  for  Sys¬ 
tems  and  Equipment.  A  primary  goal  of  the  DoD 
standards  is  to  provide  a  structure  that  standardizes 
the  conventions  and  methods  used  to  evaluate  design 
characteristics  that  most  influence  the  availability  and 
the  life  cycle  cost  of  a  system.  Standardization,  in 
turn,  permits  quantitative  comparisons  across  systems 
in  the  form  of  cost/benefit  analysis  and  "trade  stu¬ 
dies"  that  facilitate  design  decisions. 

Although,  intuitive  to  many  in  concept,  application  of 
developmental  supportability  engineering  and  logistics 
analytical  conventions  to  influence  system  design  dur¬ 
ing  development  is  inherently  difficult.  The  ability  to 
predict  the  support  requirements  likely  to  result  from 
a  particular  set  of  design  characteristics  is  limited 
significantly  by  design  immaturity  and  the  lack  of 
available  performance  data  from  similar  systems 
operated  in  similar  environments.  As  the  design 
matures,  developmental  test  and  analysis  efforts  logi¬ 
cally  generate  increasingly  more  accurate  system 
performance  data,  and  permit  correspondingly  more 
accurate  predictions  about  the  availability  and  life 
cycle  cost  of  the  final  product.  However,  as  the 
design  matures,  changes  logically  become  more  and 
more  expensive  to  effect.  Cost  ceilings  and  schedule 
constraints  increasingly  limit  design  flexibility  and  the 
probability  increases  that  an  opportunity  to 
significantly  improve  system  availability  or  decrease 
life  cycle  support  costs  might  be  lost. 

Compounding  the  negative  effects  of  competing  design 
constraints  on  the  ultimate  availability  and  life  cycle 
support  cost  of  a  fielded  system  are  the  arguably  more 
manageable  problems  associated  with  integrating  the 
independent  efforts  of  the  supportability  engineers 
and  the  logisticians  in  the  corporate  work  setting. 
Each  discipline  has  developed  its  own  dialect,  unique 
data  bases,  internal  procedures  and  schedules  that 
hinder  or  preclude  symbiotic  progress  toward  ulti¬ 
mately  identical  goals.  Lack  of  institutional  interfaces 
between  logistics  and  engineering  functions  and 
incomplete  corporate  level  understanding  of  the  two 
processes  lead  to  ineffective  up-frort  planning  and 
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result  in  inefficient  use  of  resources  and  lost  opportun¬ 
ities. 

The  authors  will  describe  an  integrative  thought  pro¬ 
cess,  derived  from  their  experience  in  both  engineering 
and  acquisition  logistics,  that  attempts  to  demonstrate 
how  the  engineering  and  logistics  analytical  processes 
can  each  benefit  from  the  other.  We  will  discuss  the 
iterative  nature  of  the  development  process  and  how 
proper  sequencing  of  analytic  efforts  is  critical  to 
efficiency  and  eventual  effectiveness.  We  will  discuss 
the  advantages  of  a  common  computer  data  base  for 
accomplishing  and  storing  engineering  and  logistics 
analysis.  Finally,  we  will  discuss  the  value  of  post- 
production  analysis  in  assessing  the  effectiveness  of 
up-front  planning  and  the  accuracy  of  estimating 
methodologies  in  predicting  the  availability  and  sup¬ 
port  cost  impacts  of  early  design  decisions. 

Integrative  Logistics/Engineering  Process 

System-level  design  parameters  that  require  minimiza¬ 
tion  of  support  resource  consumption  and  maximiza¬ 
tion  of  operational  availability  should  be  established 
in  the  earliest  stages  of  the  programs.  Examples  of 
these  types  of  requirements  are: 

Reliability 

Maintainability 

Minimization/Elimination  of  Support  Equipment 
Minimize/Standardize  Part  Types 
Facilitate  Two-Level  Maintenance 
-  100%  On- Aircraft  Fault  Isolation  to 
Lowest  Recoverable  Unit 
Minimize  Life  Cycle  Cost 


minimum  requirements.  The  vendors  must  also  be 
required  to  provide  the  necessary  data  to  the  system 
developer  to  support  system  analysis. 

Data  elements  required  to  support  this  process 
include: 

Reliability 

Mean  Time  Between  Maintenance  (MTBM) 

Mean  Time  Between  Removal  (MTBR) 

Mean  Time  Between  Failure  (MTBF) 

Maintainability 

Mean  Time  to  Repair  (MTTRI 
Maintenance  Manllours  per  Flying  Hour 
(MMH/FH) 

Cost 

Support  Equipment  Cost 
Spares  Cost 
Facilities  Cost 

Turn-Around  Time 
Transportation 
Packaging 
Shipping 
Repairing 

Iterative  Analysis  Process 

The  system  developer  must  be  responsible  for  accom¬ 
plishment  of  all  analyses  to  demonstrate  compliance 
with  the  supportability  requirements.  These  analyses 
typically  include: 


Utilization  of  this  "performance-based"  concept  allows 
the  developer  the  flexibility  to  optimize  the  system 
within  the  constraints  of  the  customer’s  functional 
requirements  without  imposing  unnecessarily  detailed 
design  requirements.  The  system  developer  then  has 
the  responsibility  to  allocate  the  system  level  require¬ 
ments  to  the  lowest  recoverable  unit  level  based  on 
the  best  available  data. 

As  the  hardware  design  takes  shape,  the  systems 
engineers  and  logisticians  must  take  the  available 
design  data  and  predict  the  capability  of  the  design  to 
meet  the  performance  requirements.  Typically,  the 
engineers  conduct  iterative  reliability,  maintainability 
and  availability  analyses,  while  the  logisticians  predict 
life  cycle  cost,  spares  quantities  and  optimum  repair 
level.  The  results  of  these  analyses  must  then  be  com¬ 
pared  to  system-level  requirements  and  to  the  indivi¬ 
dual  unit’s  allocated  requirements. 

A  rank  order  list  of  units  which  are  driving  perfor¬ 
mance  or  support  costs  to  unacceptable  levels  should 
be  prepared  and  passed  on  to  the  design  groups.  The 
design  of  these  items  should  then  be  examined  to 
ensure  that  all  practical  means  have  been  taken  to 
achieve  the  units  allocated  requirements.  If  the  unit 
can  not  reasonably  be  expected  to  achieve  it’s  allo¬ 
cated  requirements,  the  system-level  performance  con¬ 
cept  allows  the  developer  flexibility  to  re-allocate 
among  the  components  of  the  system  (i.e.;  a  system 
which  was  exceeding  its  allocated  requirement  may 
have  its  allocation  raised  in  order  to  lower  the  alloca¬ 
tion  of  a  system  not  achieving  it’s  requirement). 

Major  system  component  vendors  should  be  included 
in  the  allocation  process.  Allocations  to  vendor  com¬ 
ponents  should  be  flowed-down  to  the  vendor’s 
specification.  Warranties  and  incentives  should  be 
considered  to  ensure  performance  that  meets 


Engineering 

Operational  Effectiveness 
Modeling  (Availability) 

R&M  Allocation  Sc 
Predictions 

Failure  Modes,  Effects  Sc 
Criticality  Analysis 
Support  Equipment 
Requirements 
Preliminary  Sc  Final 
Design 

Many  of  these  analyses  have  multiple  purposes.  For 
example,  Failure  Modes,  Effects  and  Criticality 
Analysis  (FMECA)  is  used  by  engineering  to  evaluate 
the  design  for  its  fault  tolerance  and  to  demonstrate 
compliance  with  flying  safety  requirements.  FMECA 
is  required  by  logistics  to  identify  failure  modes  which 
will  require  subsequent  fault  isolation  and  repair  pro¬ 
cedures.  Engineering  is  generally  the  only  agency 
with  adequate  knowledge  of  the  system  design  to 
prepare  a  FMECA.  However  if  engineering  prepared 
the  FMECA  only  to  satisfy  their  own  requirements, 
significant  data  required  to  support  logistics  efforts 
would  be  not  be  generated.  Similarly,  operational 
effectiveness  models  generated  by  engineering  will  be 
dependent  on  the  logistics  support  concept,  and  there¬ 
fore  plans  must  be  made  by  logistics  to  provide 
engineering  with  their  planned  maintenance  concept 
and  manpower,  turnaround  times,  repair  level,  spares 
requirements,  etc. 

Thus,  to  increase  the  effectiveness  of  the 
developmental  supportability  efforts,  engineering  and 
logistics  must  jointly  identify  their  data  requirements 
and  need  dates.  It  must  be  assumed  from  the  outset 
that  these  efforts  will  be  iterative.  Both  organizations 
must  plan  to  update  their  analyses  with  new,  increas¬ 
ingly  detailed  and  accurate  information. 


Repair  Level  Analysis 

Reliability  Centered 
Maintenance 
Provisioning 

Fault  Isolation 
Procedures 
Manpower  Levels 
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Detailed  Data  Requirements 

Typically,  logistics  support  analysis  will  require  the 
following  information  from  engineering: 

Reliability  Data 

Comparative  Analysis 

Analytical  Prediction  (MIL-HDBK-217) 

Test  Results 

Maintainability  Data 
Failure  Modes 

Diagnostics  Method  (BIT,  SE,  or  manual) 

Physical  Configuration 

Usage  Data  (Operating  time  versus  calendar  time) 

Support  Equipment  Requirements 
Common 
Peculiar 
Quantities 

Engineering  Drawing  Data 
Accessibility 

Engineering  will  look  to  logistics  for  guidance  in  selec¬ 
tion  of  design  alternatives.  In  many  cases  there  are 
several  acceptable  design  alternatives  from  a  func¬ 
tional  standpoint,  in  these  instances  logistics  can 
impact  the  design  by  providing  analyses  to  rank  the 
alternatives  in  terms  of  support  cost.  Also,  some 
design  alternatives,  which  meet  all  performance 
requirements,  may  be  completely  unacceptable  to  the 
logistics  community  because  of  large  life  cycle  support 
costs  associated  with  supporting  the  design. 

Sequence  of  Information  Flow 

The  timing  of  data  flow  will  be  essential  to  optimizing 
the  system’s  performance.  Data  must  flow  to  the  sup¬ 
port  community  in  time  for  them  to  analyze  it  and 
flow  back  their  results  to  the  design  engineers  before 
it  is  too  late  to  make  cost  effective  changes.  The  need 
for  detailed  data  must  be  balanced  against  its  availa¬ 
bility.  In  most  cases,  analysis  must  be  begun  with 
preliminary,  "high-level"  data,  then  be  refined  as  the 
design  matures.  A  typical  sequence  of  events  would 
be  as  follows: 


1)  Engineering  must  estimate  performance  of  the 
preliminary  design,  both  at  the  system  level  and  the 
major  component  level  (Tine  Replaceable  Unit  (LRU). 
These  estimates  would  include  reliability,  maintaina¬ 
bility,  diagnostic  method,  etc. 

2)  These  estimates  would  be  used  by  logistics  to  esti¬ 
mate  the  life  cycle  cost  of  supporting  the  system  and 
used  bye  engineering  to  assess  the  design  compliance 
with  operational  effectiveness  requirements.  The 
major  system  components  should  then  be  ranked  by 
negative  impact  to  support  cost  and  operational 
effectiveness. 

3)  Engineering  should  then  respond  to  the  drivers  by 
searching  for  design  alternatives  or  enhancements  that 
will  reduce  support  costs  or  enhance  operational 
effectiveness  without  severely  impacting  performance 
or  schedule. 

4)  When  the  alternatives  have  been  identified,  both 
engineering  and  logistics  should  conduct  a  detailed 
cost/benefit  analysis  to  arrive  at  the  optimum  design 
solution. 


5)  The  selected  design/support  concept  should  then 
be  finalized.  The  objective  for  completion  of  this  ini¬ 
tial  round  of  trade  studies  should  be  Preliminary 
Design  Review  (PDR). 

6)  Following  PDR  the  selected  system  design  and 
support  concept  can  be  analyzed  in  greater  detail. 
The  operational  effectiveness  and  support  cost  models 
should  be  continuously  refined  as  the  design  becomes 
more  and  more  mature.  The  logistics  support  concept 
should  also  be  reevaluated  as  the  design  matures. 

7)  At  CDR,  the  hardware  design  should  be  complete. 
The  support  cost  and  operational  effectiveness  models 
should  reflect  the  current  design.  All  data  should  be 
available  to  provide  estimates  of  system  performance 
against  requirements.  Beyond  this  point,  the  practi¬ 
cality  of  changing  the  design  to  reduce  support  costs 
or  improve  availability  diminishes. 

8)  Following  CDR,  test  results  should  be  used  to  vali¬ 
date  the  predictions  used  in  the  models.  Proposed 
spare  quantities,  numbers  of  support  equipment  and 
manpower  allocations  may  still  be  changed,  but 
design  impact  will  be  unlikely. 

It  is  obvious  to  anyone  who  has  been  involved  in  the 
development  of  a  complex  system  that  the  cost  of 
changing  the  design  increases  exponentially  as  the 
development  process  continues.  Therefore,  the  logis¬ 
tics  and  supportability  engineering  communities  must 
be  prepared  to  evaluate  the  design  as  efficiently  and 
quickly  as  possible.  A  well-trained,  prepared  group  of 
engineers  and  logisticians  is  most  valuable  early  in  the 
program.  Prepared  with  the  right  analytical  tools,  a 
small  group  can  have  an  effective  input  to  the  prelim¬ 
inary  design.  Unfortunately,  engineering  and  logistics 
traditionally  do  not  effectively  exchange  information. 
This  results  in  inefficiencies  and  delays  accomplish¬ 
ment  of  the  objectives  of  a  design  optimized  for  sup- 
portability. 

Shared  DataBase 

A  shared  database  can  be  used  to  improve  the  com¬ 
munication  between  the  engineering  and  logistics  com¬ 
munities.  At  the  beginning  of  the  development  effort, 
both  logistics  and  engineering  should  define  the  efforts 
which  will  require  an  exchange  of  information.  All 
required  data  elements  required  to  support  the  efforts 
should  also  be  identified  and  defined. 

Based  on  this  list  of  data  elements,  a  common  data¬ 
base  should  be  created.  This  database  should  be 
accessible  to  the  both  the  people  who  generate  the 
information  as  well  those  who  will  use  it.  This  can  be 
effectively  accomplished  via  a  distributed  computer 
network  with  centralized  data  storage. 

Currently,  many  companies  depend  on  a  paper  com¬ 
munication  system.  For  example,  FMECAs  are  gen¬ 
erated  by  engineering  using  some  type  of  automated 
system  and  then  distributed  by  hard-copy  to  all  users. 
Much  of  the  information  contained  in  a  FMECA  can 
be  transferred  directly  to  the  Logistics  Support 
Analysis  Record  (LSAR)  required  on  many  current 
programs.  In  many  cases,  because  no  planning  was 
done  to  ensure  that  data  systems  were  compatible, 
this  data  must  be  re-keyed  by  logistics  personnel  from 
the  hard  copy  into  the  computer  system  used  to  gen¬ 
erate  the  LSAR. 

An  additional  communication  problem  can  be  created 
when  logistics  receives  source  data  from  other  organi- 


zations  that,  because  of  definitional  differences,  cannot 
be  used  directly.  This  may  cause  an  analyst  to  make 
an  adjustment  to  a  value  that  could  have  been 
directly  transferred  if  definitions  had  been  determined 
jointly.  (How  many  different  definitions  of  MTBF 
exist?)  Again,  joint  development  of  the  parameters  to 
be  used  and  their  definitions  could  have  reduced  the 
manpower  required  to  complete  the  analysis. 

Database  incompatibility  robs  manpower  that  could 
be  used  for  much  more  effective  purposes.  When 
beginning  a  development  effort,  planning  and  prepara¬ 
tion  are  required  to  ensure  that  resources  are  utilized 
effectively.  There  are  three  major  supportability 
functions  occurring  simultaneously,  yet  often  indepen¬ 
dently,  in  every  development  program.  These  three 
functions  must  be  integrated  such  that  information 
flow  is  enhanced,  not  impeded.  The  three  functions 
are  as  follows: 

1)  Reliability  &  Maintainability  Engineering 

Allocations 

Predictions 

FMECA 

Diagnostics 

Operational  Effectiveness  Modeling 

2)  MIL-STD-1388  Logistics  Support  Analysis 
RLA 

Provisioning 

Maintenance  Task  Analysis 

3)  Life  Cycle  Cost  Analysis 


All  three  of  these  functions  are  simultaneously  gen¬ 
erating  and  using  information.  This  information  flow 
must  be  understood,  planned  and  prepared  for  to 
avoid  needless  duplication  of  effort.  The  support 
analysis  effort  must  be  accomplished  in  a  timely 
manner  if  the  design  impact  discussed  previously  is  to 
take  place. 

The  integration  we  propose  is  not  something  that 
requires  a  state-of-the-art  computer  system,  or  the 
arrival  of  some  long-awaited  break  through  in  data 
standardization.  Current  computer  technology  in 
place  at  most  companies  should  easily  enable  the 
automated  transfer  of  most  data. 

This  situation  can  become  more  complicated  when 
different  groups  are  using  different  parameters  for  the 
same  quantity,  or  have  different  definitions  for  the 
same  parameter.  This  can  all  be  avoided  by  requiring 
a  common  database,  common  parameters,  and  com¬ 
mon  definitions  for  those  parameters.  In  this  manner, 
when  the  reliability  engineer  enters  the  latest  predic¬ 
tion  for  any  component  of  the  system  it  is  automati¬ 
cally  entered  in  the  LCC  analysis,  the  LSAR,  the 
FMECA,  the  RLA,  etc. 

This  same  integrative  concept  should  be  applied  to 
vendor/subcontractor  supplied  information.  Specify¬ 
ing  that  the  work  be  done  in  accordance  with  a  mili¬ 
tary  standard  does  not  guarantee  that  the  data  pro¬ 
vided  will  be  in  a  standard  format  or  be  accomplished 
using  similar  methods.  In  order  to  ensure  a  quick, 
painless  integration  of  the  vendor  data  into  the 
prime’s  data  system,  the  vendor  should  be  brought  on 
the  team.  Data  will  always  be  required  in  hardcopy. 
However  if  the  vendor  is  instructed  to  do  so,  the  ven¬ 
dor  data  can  easily  be  made  available  on  computer 
media  also,  and  may  be  easily  uploaded  to  the  prime’s 
computer  database. 


For  example,  most  companies’  reliability  predictions 
are  created  and  stored  in  some  type  of  computer  data¬ 
base.  These  reliability  figures  are  then  required  to 
support  virtually  every  other  supportability  analysis 
effort,  such  as  LCC  analysis,  LSAR,  RCM,  RLA,  and 
any  operational  effectiveness  models,  most  of  which 
are  also  computerized.  In  most  cases  the  reliability 
predictions  will  be  manually  reentered  into  most  of 
these  other  computerized  analysis  systems.  Because  of 
the  large  amount  of  manual  effort  required,  the  users 
of  this  reliability  data  are  not  anxious  to  update  their 
analyses  as  more  current  reliability  predictions 
become  available. 

One  method  to  accomplish  the  transfer  of  this  data 
among  the  users  would  be  to  require  each  organiza¬ 
tion  to  use  a  common  computer  and  common  data¬ 
base  system  (i.e.  ORACLE,  INGRES,  etc.)  for  their 
analysis.  If  all  analysis  systems  are  linked  on  a  single 
computer  systems,  then  all  analyses  can  be  immedi¬ 
ately  updated  when  any  single  data  element  in  the 
system  is  changed. 

Although  this  may  be  the  simplest  solution,  it  is  prob¬ 
ably  the  least  practical.  Generally,  each  analysis  is 
already  being  accomplished  via  some  specialized  pro¬ 
gram.  These  programs  may  be  running  on  everything 
from  PC’s  to  mainframes.  However,  most  programs 
can  create  and  read  straight  alphanumeric  data 
(ASCII).  If  the  parameters  to  be  exchanged  are 
jointly  defined,  and  input/output  file  formats  are 
known,  data  can  be  shared  via  magnetic  tape,  floppy 
disk,  etc.  With  this  arrangement,  data  can  be  shared 
at  specific  points,  either  calendar  time  intervals  (i.e.; 
weekly,  monthly,  etc)  or  on  an  event  based  schedule 
(PDR,  CDR,  LSA  Review,  etc.). 

It  is  impossible  to  define  one  method  that  will  work  at 
every  site,  but  the  important  thing  is  to  plan  for  the 
data  transfer.  Determine  the  primary  elements  of 
data  that  must  be  transferred  from  group  to  group, 
and  rank  them  based  on  the  negative  impact  of  hav¬ 
ing  to  transfer  the  data  manually.  Then  evaluate  the 
time  and  effort  required  to  automate  the  transfer  of 
the  information.  In  this  manner  the  automation  pro¬ 
cess  can  be  prioritized  based  on  the  impact. 

Conclusion 

The  process  of  influencing  design  to  minimize  support 
cost  and  maximize  operational  effectiveness  is  highly 
dependent  on  the  flow  of  information  between  organi¬ 
zations.  Without  the  timely  flow  of  data  between 
engineering  and  logistics  the  desired  design  influence 
cannot  be  obtained.  In  the  first  stages  of  the  pro¬ 
gram,  engineering  and  logistics  must  identify  and 
define  the  data  elements  that  will  flow  between  the 
two  organizations.  Then  the  method  which  will  be 
used  to  efficiently  transfer  this  data  must  be  chosen. 
Finally  a  schedule  identifying  which  data  is  required 
to  support  intermediate  program  milestones  must  be 
arrived  at  jointly. 

Properly  planned  and  implemented,  a  supportability 
analysis  program  combining  both  engineering  and 
logistics  can  have  a  tremendous,  positive  impact  on 
the  supportability  of  the  fielded  product.  With  sup¬ 
portability  analysis  integrated  with  design,  the  opera¬ 
tional  weapon  system  has  a  greater  probability  of 
meeting  its  operational  effectiveness  requirements  at 
lowest  possible  support  cost. 
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